…getsentry#6202)

The HTTP client span in the stdlib integration was finishing in
`getresponse()`, which only waits for response headers, not the actual
response. For chunked or large responses, the actual data transfer
happens during `read()`, leaving that time uninstrumented.

Defer span completion to `HTTPResponse.read()` for responses with a body
(chunked or Content-Length > 0), with `HTTPResponse.close()` as a safety
net for responses that are never read.

⚠️ Note that this means we might report some requests to be longer than
they actually were, since in some cases we only close them once the GC
gets to them (and `close()` is called). In a sense we're essentially
flipping the current situation (where we report requests to be much
shorter than they are, since they don't include the response part) --
but the current situation was incorrect for all spans, while this
`close()` fallback should hopefully only kick in for edge cases.

Responses with no body (Content-Length: 0, HEAD, 204, 304) still finish
the span immediately in `getresponse()`.

* Closes getsentry#2277
* Closes
https://linear.app/getsentry/issue/PY-159/sentry-does-not-fully-instrument-requests-library-requests

---------

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Alex Alderman Webb <alexander.webb@sentry.io>

…ms` (getsentry#6233)

We had multiple `envelopes_to_x` helpers around in tests for unwrapping
metrics, logs, and spans. Replace them all with `capture_items`, which
has the added benefit of being more true to the actual payload leaving
the SDK, unlike `envelopes_to_x`, which used to modify some fields
(setting them to `None` if they were not present, for instance).

Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>

Just moving one test case to another file.

### Description
Reintroducing the argv integration port from
getsentry#6147. Work on full
support for array attributes in the product is still ongoing, but at
least the trace will now load (the attribute won't be displayed), so
we're not breaking anything with this change.

#### Issues
- Closes getsentry#5998
- Closes
https://linear.app/getsentry/issue/PY-2300/migrate-argv-to-span-first

#### Reminders
- Please add tests to validate your changes, and lint your code using
`tox -e linters`.
- Add GH Issue ID _&_ Linear ID (if applicable)
- PR title should use [conventional
commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type)
style (`feat:`, `fix:`, `ref:`, `meta:`)
- For external contributors:
[CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md),
[Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord
community](https://discord.gg/Ww9hbqr)

### Description
See getsentry#6217

#### Issues
* Resolves
https://linear.app/getsentry/issue/PY-2407/force-a-new-segment-where-we-were-creating-transactions
* Resolves getsentry#6217

#### Reminders
- Please add tests to validate your changes, and lint your code using
`tox -e linters`.
- Add GH Issue ID _&_ Linear ID (if applicable)
- PR title should use [conventional
commit](https://develop.sentry.dev/engineering-practices/commit-messages/#type)
style (`feat:`, `fix:`, `ref:`, `meta:`)
- For external contributors:
[CONTRIBUTING.md](https://github.com/getsentry/sentry-python/blob/master/CONTRIBUTING.md),
[Sentry SDK development docs](https://develop.sentry.dev/sdk/), [Discord
community](https://discord.gg/Ww9hbqr)

…etsentry#6236)

Changing `sentry_sdk.trace` to `sentry_sdk.traces.trace` introduced a
whole avalanche of [typing
issues](https://github.com/getsentry/seer/actions/runs/25495762136/job/74814929830?pr=6291).

Adding the overloads we have for the original `trace`.

The field capturing the end timestamp of a span used to be called
`timestamp` in legacy mode (on the `Span` class), with `start_timestamp`
as its counterpart.

In span streaming, we originally followed the same convention on the new
`StreamedSpan` class, but there's actually no reason to and it'd be
better to use `end_timestamp` instead:
- the field on the serialized span v2 is actually called `end_timestamp`
- `end_timestamp` is a clearer name in general, and complements
`start_timestamp` nicely